Many communications solutions implement a synchronous communication model—requiring a dedicated logical connection between sender and receiver for the communication to succeed. For example, Web browser HTTP requests and responses are synchronous—the requesting Web browser typically sends a request and waits for a response from the Web server before continuing with any other processing. The initial HTTP request includes a Uniform Resource Locator (URL) specifying the Web page that the user of the Web browser requires. An Internet user may initiate a conversational flow of requests and responses, such as when enquiring about and then ordering a product, and it may be necessary for one or more of the flows to be encrypted to protect the user's credit card details or other personal information. The conventional approach to providing such security uses Secure Sockets Layers (SSL) which provides all-or-nothing encryption across a communication link but does not provide end-to-end security between application programs.
Asynchronous communication models are also well known, such as implemented by a number of commercially available message-oriented middleware products. Middleware products support communications between application programs across a network. These include IBM Corporation's MQSeries and WebSphere MQ family of messaging products, which use asynchronous messaging via queues. A sender application program issues a PutMessage command to send a message to a target queue, and MQSeries queue manager programs handle the complexities of transferring the message from the sender to the target queue, which may be remotely located across a heterogeneous computer network. The MQSeries queue manager programs implement transactional assured message delivery even when the destination application is not available at the time the message was sent. The target queue is a local input queue for another application program, which retrieves the message from its input queue by issuing a GetMessage command asynchronously from the send operation. The receiver application program then performs its processing on the message, and may generate further messages.
IBM Corporation's MQSeries Everyplace product is an example of a messaging product which implements asynchronous communications as described above as well as a form of synchronous communication. That is, a local MQSeries Everyplace queue manager can (1) Put a message to a local queue and then return control to the sending application (the local queue may be a proxy for a remote queue, with asynchronous message transfer between the local proxy and the remote destination queue being trusted to the queue manager programs), or (2) it can implement a PutMessage operation to place the message on a remote queue and only return control when the message is confirmed to have arrived at the target queue. In both cases, a PutMessage operation is followed by a subsequent GetMessage operation to take the message from the target queue, and so the overall application-to-application communication is asynchronous. IBM's MQSeries Everyplace product has been developed using object-oriented (OO) programming techniques. (IBM, WebSphere, MQSeries and Everyplace are trademarks of International Business Machines Corporation).
As is well known in OO programming, objects are instances of classes which are abstract definitions of the characteristic attributes and functions (known as methods) of a named data type which represents a real world entity. Thus each class is an abstraction of a real world entity. An object includes attribute data and the class functions (methods) which operate on that data. The data and class functions are tightly bound together within the object, and this integration of data and class functions within an object is known as encapsulation. Another important concept of OO programming is inheritance—that is, classes can implement a hierarchy in which all descendant classes of a base class include all of its characteristic attributes and class functions, and add additional attributes or class functions.
The Object Management Group's Common Object Request Broker Architecture (CORBA) is a distributed object computing architecture supporting interoperability between object-oriented applications across a network. CORBA applications are composed of objects (individual executable software components that combine functionality and data). Objects can invoke operations on other objects by sending local or remote invocation requests via a defined interface—effectively calling a method on a target object, and including an object reference as a parameter of the invocation request. An Object Request Broker (ORB) associated with the originator of the request examines an object reference within the invocation request to discover where the target object is and, for remote target objects, routes the invocation request over the network to the remote object's ORB. Thus, the ORBs provide a mechanism for transparently communicating client requests to target objects. Requesting clients know the type of object they are invoking and so they know which operations can be invoked, what the inputs are and where they should go in the invocation. As described by Douglas Schmidt and Steve Vinoski in “An Introduction to CORBA Messaging”, SIGS C++ Report, Vol. 10, No 10, November/December, 1998, CORBA messaging currently supports both synchronous and asynchronous communications between objects.
Known inter-program communications in a distributed network, whether synchronous or asynchronous, may specify what operations are to be performed by a recipient or they may transmit data for a recipient to interpret, and it is known for communications to include complex data structures. However, typical inter-program communications do not include executable functions. This represents a failure to fully utilize the opportunities of OO programming.
IBM Corporation's MQSeries Everyplace product enables objects to be transmitted across a network. Both data and executable functions can be transmitted by embedding an object within a message which is transmitted in response to PutMessage command. The transmitted message is placed in a message queue, from where it is asynchronously retrieved by a receiver application program which issues a GetMessage request. This object transmission provides considerable advantages for efficient inter-program communications, while preserving the asynchronous semantics of a Put followed by a Get.